单号|前文_防止重复下单分布式系统接口幂等性实现方案

篇首语：本文由编程笔记#小编为大家整理，主要介绍了防止重复下单分布式系统接口幂等性实现方案相关的知识，希望对你有一定的参考价值。

问题背景

最容易想到的使用数据库事务。
比如创建订单时&＃xff0c;要同时往订单表、订单商品表插入数据&＃xff0c;那这些插入数据的INSERT必须在一个数据库事务执行&＃xff0c;数据库事务可保证&＃xff1a;执行这些INSERT语句&＃xff0c;同生共死!

订单服务调用支付服务&＃xff0c;不巧网络超时&＃xff0c;然后订单服务走重试机制&＃xff0c;给你重试了一把&＃xff0c;支付服务收到一个支付请求两次&＃xff0c;而且因为轮询负载均衡算法落在不同机器&＃xff01;
所以一个分布式系统中的接口&＃xff0c;要如何保证幂等性呢&＃xff1f;

如何避免重复下单&＃xff1f;

评论里有同学说&＃xff0c;前端页面直接防止用户重复提交表单。没啥毛病&＃xff0c;但网络错误会导致重传&＃xff0c;很多RPC框架、网关都有自动重试机制&＃xff0c;所以重复请求无法避免。问题最终还是归结于如何保证服务接口的幂等性。

如何判断请求是重复的&＃xff1f;

• 插入订单前&＃xff0c;先查一下订单表里面有无重复订单?
  这可不好&＃xff0c;你很难用SQL条件定义什么是“重复订单”

• 订单的用户、商品、价格一样就是重复订单?
  万一这用户就是连续下了俩一模一样订单呢&＃xff01;

所以保证幂等性要做到如下几点&＃xff01;

每个请求须有唯一标识

比如订单支付请求&＃xff0c;得包含订单id&＃xff0c;一个订单id最多支付一次&＃xff01;

每次处理完请求后&＃xff0c;须有记录标识该请求已被处理

在mysql中记录一个状态字段。比如支付之前记录一条这个订单的支付流水。

每次接收请求判断之前是否处理过

若有一个订单已支付&＃xff0c;就已经有了一条支付流水。若重复发送这个请求&＃xff0c;则此时先插入支付流水&＃xff0c;orderId已存在&＃xff0c;唯一键约束生效&＃xff0c;报错插入不进去。就不会再重复扣款。

在往db插条记录时&＃xff0c;一般不提供主键&＃xff0c;而由数据库在插入时自动生成一个主键。这样重复的请求就会导致插入重复数据。
MySQL的主键自带唯一性约束&＃xff0c;若在一条INSERT语句提供主键&＃xff0c;且该主键值在表中已存在&＃xff0c;则该条INSERT会执行失败。因此可利用db的“主键唯一约束”&＃xff0c;在插数据时带上主键&＃xff0c;以此实现创建订单接口的幂等性。

给订单服务添加一个“orderId生成”的接口&＃xff0c;无参&＃xff0c;返回值就是一个全局唯一订单号。在用户进入创建订单页面时&＃xff0c;前端页面先调用该orderId生成接口得到一个订单号&＃xff0c;在用户提交订单的时候&＃xff0c;在创建订单的请求中携带该订单号。

该订单号其实就是订单表的主键&＃xff0c;如此一来&＃xff0c;重复请求中带的都是同一订单号。订单服务在订单表中插入数据的时候&＃xff0c;执行的这些重复INSERT语句中的主键&＃xff0c;也都是同一个订单号。而数据库的唯一约束可保证&＃xff0c;只有一次INSERT执行成功。

实际要结合业务&＃xff0c;比如使用Redis&＃xff0c;用orderId作为唯一键。只有成功插入这个支付流水&＃xff0c;才可执行扣款。

要求是支付一个订单&＃xff0c;必须插入一条支付流水&＃xff0c;order_id建立一个唯一键。
你在支付一个订单前&＃xff0c;先插入一条支付流水&＃xff0c;order_id就已经传过去了。就可以写一个标识到Redis中&＃xff0c;set order_id payed&＃xff0c;当重复请求过来时&＃xff0c;先查Redis的order_id对应的value&＃xff0c;若为payed说明已支付&＃xff0c;就别重复支付了!

然后再重复支付订单时&＃xff0c;写尝试插入一条支付流水&＃xff0c;db会报唯一键冲突&＃xff0c;整个事务回滚即可。
保存一个是否处理过的标识也可以&＃xff0c;服务的不同实例可以一起操作Redis。

• 幂等创建订单的时序图
  

如果因为重复订单导致插入订单表失败&＃xff0c;订单服务不要把这个错误返回给前端页面。否则&＃xff0c;就可能出现用户点击创建订单按钮后&＃xff0c;页面提示创建订单失败&＃xff0c;而实际上订单却创建成功了。正确的做法是&＃xff0c;遇到这种情况&＃xff0c;订单服务直接返回订单创建成功即可。

3.1 什么是 ABA?

比如订单支付后&＃xff0c;卖家要发货&＃xff0c;发货完成后要填个快递单号。假设说&＃xff0c;卖家填了个666&＃xff0c;刚填完&＃xff0c;发现填错了&＃xff0c;赶紧再修改成888。对订单服务来说&＃xff0c;这就是2个更新订单的请求。系统异常时666请求到了&＃xff0c;单号更成666&＃xff0c;接着888请求到了&＃xff0c;单号又更新成888&＃xff0c;但是666更新成功的响应丢了&＃xff0c;调用方没收到成功响应&＃xff0c;自动重试&＃xff0c;再次发起666请求&＃xff0c;单号又被更新成666了&＃xff0c;这数据显然就错了.

• 时序图
  

3.2 解决方案

通用的解决方案

订单主表增加一列version。每次查询订单的时候&＃xff0c;版本号要随着订单数据返回给页面。
页面在更新数据的请求中&＃xff0c;把这个版本号作为更新请求的参数&＃xff0c;带回给订单更新接口。

订单服务在更新数据的时候&＃xff0c;需要比较订单的版本号是否和消息中的一致:

• 不一致 拒绝更新数据
• 一致 还需要再更新数据的同时&＃xff0c;把版本号&＃43;1。“比较版本号、更新数据和版本号&＃43;1”&＃xff0c;这个过程必须在同一个事务里面执行。

UPDATE orders set tracking_number &＃61; 666, version &＃61; version &＃43; 1
WHERE version &＃61; 8;


在这条SQL的WHERE条件中&＃xff0c;version的值需要页面在更新的时候通过请求传进来。

通过这个版本号&＃xff0c;就可以保证&＃xff0c;从我打开这条订单记录开始&＃xff0c;一直到我更新这条订单记录成功&＃xff0c;这个期间没有其他人修改过这条订单数据。因为&＃xff0c;如果有其他人修改过&＃xff0c;数据库中的版本号就会改变&＃xff0c;那我的更新操作就不会执行成功。我只能重新查询新版本的订单数据&＃xff0c;然后再尝试更新。

有了这个版本号&＃xff0c;前文的ABA即有两个 case

• 把运单号更新为666的操作成功了&＃xff0c;更新为888的请求带着旧版本号&＃xff0c;那就会更新失败&＃xff0c;页面提示用户更新888失败
• 第二种情况&＃xff0c;666更新成功后&＃xff0c;888带着新的版本号&＃xff0c;888更新成功。这时候即使重试的666请求再来&＃xff0c;因为它和上一条666请求带着相同的版本号&＃xff0c;上一条请求更新成功后&＃xff0c;这个版本号已经变了&＃xff0c;所以重试请求的更新必然失败

无论哪种情况&＃xff0c;数据库中的数据与页面上给用户的反馈都是一致的。这样就可以实现幂等更新并且避免了ABA问题

• 下图展示case1
  

• 对于创建订单服务来说&＃xff0c;可以通过预先生成订单号&＃xff0c;然后利用数据库中订单号的唯一约束这个特性&＃xff0c;避免重复写入订单&＃xff0c;实现创建订单服务的幂等性
• 对于更新订单服务&＃xff0c;可以通过一个版本号机制&＃xff0c;每次更新数据前校验版本号&＃xff0c;更新数据同时自增版本号&＃xff0c;这样的方式&＃xff0c;来解决ABA问题&＃xff0c;确保更新订单服务的幂等性。

两种幂等的实现方法&＃xff0c;就可以保证&＃xff0c;无论请求是不是重复&＃xff0c;订单表中的数据都是正确的。

实现订单幂等的方法&＃xff0c;完全可以套用在其他需要实现幂等的服务中&＃xff0c;只需要这个服务操作的数据保存在数据库中&＃xff0c;并且有一张带有主键的数据表即可